Hey @rmosolgo – could you provide any more detail here? This memory would really help finding the horcruxes :)

Derp... sorry! I think it must have to do with this: f591d98

I'm going to take a stroll down memory lane and if I can remember or rediscover the issue, I'll update this doc and follow up here.

Ok, I updated the note here: 4d325ef

I think it's possible that this compatibility issue could be resolved now, because Schema::Visibility does have a top-level map of types, created by this code here:

If it looks like your schema is affected by this issue, let me know and I'll give it a shot.

Invaluable context, thanks for the quick reply. I'm going to read that new sentence on repeat this afternoon until it clicks. Also, my gosh – abstracts are hard.

Ha! If I've understood it properly, a minimal situation is like this:

class Thing < GraphQL::Schema::Object 
  implements Thingable 
end 

module Thingable 
  include GraphQL::Schema::Interface 
  field :f, String 
end 

class SomeUnion < GraphQL::Schema::Union
  possible_types(Thing)
  def self.visible?(...); false; end 
end 

class Query < GraphQL::Schema::Object
  field :thingable, Thingable 
  field :some_union, SomeUnion
end 

Going from old to new, I think the difference in visible schema would be this:

  type Query { 
    thingable: Thingable 
   }
 
  interface Thingable { 
    f: String 
  }

- type Thing implements Thingable { 
-   f: String 
- }

Visibility wouldn't check SomeUnion and discover Thing -- but Warden would, because it used the top-level map from Schema.types. To acheive compatibility, you'd have to add:

module Thingable 
  # ...
  orphan_types(Thing)
end 

Or add field :thing, Thing to Query -- just some way to discover Thing while traversing visible members of the schema.

But this might be fixable now...

Ie: anything that's not the interface membership?

Yes, that's what I meant by that ... sorry for the frenzied terseness :P

orphan_types is specifically for the case when an object type is only used in the schema as an implementer of an interface. It's a practical consideration because, in Rails development, we need Rails to load the Object type class so that GraphQL-Ruby can know about the interface implementation. Otherwise, the file might never be loaded.

For example, in a schema like this:

type Query {
  node(id: ID): Node 
}

interface Node {
  id: ID 
}

type Thing implements Node {
  id: ID 
 }

GraphQL-Ruby would need Node.orphan_types(Thing).

One last question then... how does Schema.orphan_types differ from Interface.orphan_types? I haven't always used the later but haven't noticed unexpected side effects. Is schema orphan types all-encompassing? Thanks again, this is all incredibly helpful (both for visibility upgrade and gem projects).

The two orphan_types methods are basically the same: just ways to attach things to the schema that might not be attached. I don't know of any differences between them 😅 IIRC the gem doesn't even require than an Interface's orphan types implement that interface ... Yes, always using Schema.orphan_types is a fine approach -- Schema.from_definition just passes all object types to that method!

Happy to help 🍻

Schema.from_definition proceeds to do the same work again with the interfaces themselves directly below. I think that could be removed entirely (I omitted it from the stitching composer and it seems to work?).

Ah, good catch -- I'll try removing it in #5269